In a data system, transactions refer to groups of operations that are committed or undone as a single unit. In other words, each operation in the transaction is not committed until all the operations are performed. Transaction processing in a standard database has the following benefits: atomicity (i.e., ensures that all or none of the operations in a transaction are performed), consistency (i.e., ensures that a data system remains in a consistent state before and after a transaction), isolation (i.e., ensures that intermediate data of a transaction is not accessible by other operations), and durability (i.e., ensures that once a transaction is reported as successful, the transaction will persist). However, with the advent of distributed transaction systems, transactions must be maintained over multiple servers and/or clients. In other words, a failed operation on a first server may require that an operation on a second server be undone.
Typically, distributed transactions are managed in distributed transaction systems using multi-phase commit protocols. For example, in a two-phase commit protocol, a transaction manager may monitor operations being performed on each server involved in a distributed transaction. In this example, the transaction manager ensures that all servers involved in the transaction only commit after each server has confirmed that their corresponding operations are complete. Alternatively, the transaction manager may instruct all servers involved in the transaction to undo their corresponding operations if any one of the servers fails to perform an operation.